Cable data systems are used to allow cable TV subscribers use the Hybrid-Fiber-Coax network as a communication link between their home networks and the Internet. As a result, computer information (Internet Protocol packets) can be transmitted across the Hybrid-Fiber-Coax network between home computers and the Internet. The Data Over Cable Service Interface Specification (“DOCSIS”)—defined by CableLabs®—specifies the set of protocols that must be used to effect a data transfer across the Hybrid-Fiber-Coax network (“HFC”). Two fundamental pieces of equipment facilitate this data transfer: a cable modem (“CM”) which is positioned in the subscriber's home, and a Cable Modem Termination System (“CMTS”) which is positioned in the head end of the cable TV company.
In addition to data traffic, subscribers are more and more obtaining telephony voice services over networks other than the traditional public switched telephony network (“PSTN”). A multiple services operator (“MSO”) may provide such telephony services, in addition to data over cable service via DOCSIS. For example, CableLabs has established the PacketCable™ standard for providing telephony services over cable. A subscriber typically has a device that includes a DOCSIS cable modem for transmitting and receiving data and a media terminal adaptor (“MTA”), or embedded MTA (“eMTA”) for processing voice traffic for transmission and reception over cable.
Depending on the type of traffic passing through a CMTS, various methods may be used to regulate traffic. For example, a leaky bucket, a term known in the art analogous to a bucket having a hole that rejects water from storage therein when full and when an intake flow rate exceeds a discharge flow rate, may be used to reject queuing of data packets when a storage buffer is full and the intake rate exceeds the outflow rate. When used in a packet regulating environment, a leaky bucket instantiation may be used to reject packets when the bucket is full.
A similar, but different, instantiation is known in the art as a token bucket. A token bucket can conceptually be view as a bucket that is filled with tokens, where each token represents a byte. The bucket has a fixed size, b, and is filled at a fixed rate of one token every 1/r seconds, where r is a predetermined value. When the bucket is filled with b tokens, the number of tokens in the bucket being referred to as the token depth, or fill depth, no more tokens are placed in the bucket. When a packet of size n arrives at the CMTS, if there are at least n tokens available in the token bucket (token depth>=n), for example, the packet is said to be conforming, and n tokens are taken out of the bucket (token depth reduced by n) and the packet is allowed to pass through the system. Thus, the token bucket functions as a sort of ‘credit statement.’ If there are not n tokens ‘on deposit’ when a packet of n bytes is received, the packet of n bytes is said to be non-conforming and may not be processed through the CMTS. A token bucket algorithm typically allows bursts of up to b bytes (if the bucket is full of tokens), but a constant output rate of conforming packets is generally regulated according to rate r.
If a packet is non-conforming, the system may, for example, drop the packet, or it can delay the packet until n tokens are available and the packet is then conforming. The former choice is typically referred to as policing the packets and the latter choice is typically referred to as shaping the packets.
The DOCSIS specification provides for a rate limit for packets on its service flows. The limit on the number of bytes forwarded (in bytes) during a time interval T is referred to as Max(T), and is described by the expression:Max(T)=T*(R/8)+B.  Eq. 1
The variable ‘R’ in Eq. 1 represents the Maximum Sustained Traffic Rate (in bits per second) and ‘B’ represents the Maximum Traffic Burst (in bytes). A conventional token bucket instantiation may be used to achieve the rate limitation as described by Eq. 1
Although effective in regulating the passing of large packets in a traffic flow stream, using a single token bucket to police or shape the traffic can result in a single service flow being allowed to use the entire bandwidth available while the token bucket is being emptied. This may decrease the advantage a service provider can promise with respect to higher performance in exchange for a higher subscription price when traffic is bursty and the predetermined Maximum Traffic Burst size value is large. Thus, there is a need for a method and system for increasing the regulation of bursty traffic flows that is typically provided by using a single token bucket. Furthermore, there is a need for a method and system for decreasing the bursts that comprise many small packets as opposed to one, or a few, large packets when using a token bucket for regulating a traffic flow while still regulating large packets.